Are fields like profile, number, invites, and inviter needed as part of a basic User definition? These seem to be application specific. Or at the very least I should be able to write an application that can couple a user's address with its username without the extra fields I don't care about; that seems to be the base functionality.

But it also might be helpful to provide a struct like UserData or Extended user that provides the extra fields for like applications that want to operate using this data model:

type ExtendedUser struct {
    User
    Profile string
    Number int
    Invites int
    Inviter std.Address
}

@deelawn agreed, I think it makes sense to keep those fields relevant to r/demo/users (when rendering pages and using its inviting system) so that third party realms/packages only get what they need most of the time (a name associated to an address)

These two methods also seem very application specific. I don't think there is any obvious reason to prefix usernames with @ in general. Though I do think this type can still be helpful to differentiate a string between being an address or name. This might be a good opportunity to make each method accept a usernamePrefix string argument that allows the application to decide this.

@deelawn I think the way it currently is makes a lot of sense!

r/demo/users is, to me, the "username" realm every other realm should use to identify users. p/demo/users is not meant to be the "universal" implementation for all user systems.

If we have a realm function which is, say, the following:

func SendMessage(dst users.AddressOrName, title, content string)

having users.AddressOrName as the type indicates that, unless the realm's doing something weird, the function will accept a full address or also a username prefixed with @. So I'm personally in favour to keep it this way; p/demo/users is allowed to have some opinions :)

A user storage structure seems like a great candidate for something that should be included in a users package. It makes it easy for applications to maintain and access their own user list. Something like:

type p/users.Storage struct {
    nameToUser *avl.Tree
    addresstoUser *avl.Tree
}

func (s *Storage) GetUserByName(name string) *User
func (s *Storage) GetExtendeUserByName(name string) *ExtendedUser
func (s *Storage) getUserByName(name string) interface{}{ return s.nameToUser.Get(name) }

etc
...

@deelawn I think the way it currently is makes a lot of sense!

r/demo/users is, to me, the "username" realm every other realm should use to identify users. p/demo/users is not meant to be the "universal" implementation for all user systems.

If we have a realm function which is, say, the following:

func SendMessage(dst users.AddressOrName, title, content string)

having users.AddressOrName as the type indicates that, unless the realm's doing something weird, the function will accept a full address or also a username prefixed with @. So I'm personally in favour to keep it this way; p/demo/users is allowed to have some opinions :)

@deelawn agreed, I think it makes sense to keep those fields relevant to r/demo/users (when rendering pages and using its inviting system) so that third party realms/packages only get what they need most of the time (a name associated to an address)